A job can be thought of as a combination of a program or command (i.e., what to do) and a schedule (i.e., when to do it). A job command can be any program within or outside a database, some examples include: shell scripts, executables, query language blocks, or stored procedures. Job scheduling can typically be set by a combination of date and time, a time interval, or upon receipt of a message. For example, an organization can schedule maintenance tasks to be executed daily at midnight to minimize the effect those tasks may have on user response.
The ability to schedule jobs at specific time intervals and upon the receipt of a message is helpful. However, many tasks in a database are interrelated. That is, when one task is executed another task should be executed, or similarly, when one task fails, another task is required. Current job scheduling techniques are limited in their ability to interrelate tasks or jobs and in their ability to schedule jobs based on non-job related state changes both inside and outside the database. Most current scheduling systems have a way of automatically starting a job when another one fails. However, none have a built-in way of starting a job based on a set of complex conditions. In current systems, in order to start a job based on complex conditions, the user must write a specific routine to detect the change in question and send a message to start the job.
A more sophisticated method of scheduling jobs is needed including scheduling jobs based on the status of another job and based on non-job related state changes.
A method of scheduling jobs may include creating a first job, and scheduling an event to trigger execution of the first job where the event is a state change of a second job. In another embodiment, a job scheduling system can include an event handler which enqueues events that occur in a database environment as messages in one or more queues, and a scheduler queue that manages messages based on jobs executing in the database environment.